별 문제는 없는 상태이다.

파드#정적 파드를 참고하고, api server 설정에 추가한다.

에러가 나기 시작한다.

crictl로도 api서버가 없는 걸 확인할 수 있다.

/var/logs/pods에 들어가서 로그를 확인할 수도 있다.
/var/logs/containers/에는 관련 로그들이 심볼릭 링크로 걸려있다.

원상복구하면 바로 다시 컨테이너가 올라오는 것이 확인된다.

말 그대로 해본다.
이번에는 api 서버 자체가 맛이 가는 것은 아니지만 Etcd와 연결이 되지 않는 상황
이렇게 고장내고, api server가 다시 뜰 때까지 기다린다.

이후에 crictl logs {api server id}를 확인한다.

tail -f /var/log/syslog | grep apiserver를 한 결과이다.
apiserver 파일을 파싱할 수 없다고 나온 게 가장 긴 로그.
관련한 에러도 마구 뜬다.

일단 api서버가 떠있지 않은 것인지 kubectl 자체가 먹히지 않는다.

보다시피 api 서버가 안 띄워지고 있다.
처음부터 띄워지지 않았기에 컨테이너나 파드 로그를 통해 확인도 이뤄지지 않는다.

다만 journalctl을 보면 kubelet에서 에러를 띄워주는 것이 확인된다.
일단 api서버의 양식이 제대로 파싱되지 않고 있다.

이 부분을 고쳐주었다.

이제는 컨테이너가 살았다 죽었다 하기에 로그를 볼 수 있게 되는데, 모르는 플래그가 있다고 한다.

이 친구의 이름은 authorization-mode이다.
모르면 공식 문서에서 플래그를 찾아보면 된다.

이제는 컨테이너가 실행은 되는 모습이다.

하지만 계속 재시작을 반복하는데, 23000 포트로 가는 부분이 거절된다고 나온다.

etcd로 연결하는 부분이다.

etcd는 해당 yml 파일을 보면 2379 포트를 사용한다.

이것까지 해결하니 돌아가기 시작한다.

딱히 이상은 없는 것 같다.

아예 컨트롤러 매니저가 뜨지 않고 있다.

그냥 쿠베 로그로 확인해보니 이러한 이슈가 있다.
공식 문서를 참고해봤으나, 관련한 flag는 그냥 없어서 지워버렸다.

컨트롤러가 잘 작동하여 디플로이먼트도 잘 먹는다.

과연 한 놈이 문제가 있다.

ssh로 넘어와도 되는 거였다;;
아무튼 넘어와서 확인해보면 확실히 kubelet이 문제가 있다.

journalctl로 확인해보니 이상한 플래그가 들어가있다.
kubelet은 컨테이너 런타임이기에 컨테이너의 문제를 해결하는 방법으로 해결할 수 없다.

서비스의 상태를 보고 찾아들어가서 확인해본다.

이번에는 정적파드로 해결할 수 없다.
서비스 사양을 찾아보고, 관련한 플래그가 담긴 곳을 찾아본다.

나와 있는 각 환경 파일을 찾아다니다보니, 이 놈에 improve-speed라는 놈이 있다.
이놈을 지우면, auto restart가 걸려 있어 서비스가 시작된다.
혹시 모르면 직접 재시작해도 좋다.

있긴 한데, 이렇게 문제가 발생한다.
컨테이너 생성부터 안 된다는 것.

디플과 하위 파드의 이벤트를 보니 ConfigMap에서 문제가 발생했다.

실제 놈은 이렇게 생겼으니까, 이걸 활용해야 한다.

configmap의 이름은 name쪽이다.

전부 pending에 걸려있다.

로그를 뜯어보니 단서가 나온다.
staging-node1 노드에서만 실행되도록 설정됐다.

특정 노드에 스케줄되도록 지정이 돼있다.
이러면 범용적으로 돌아갈 수는 없다.
그래서 그냥 단순히 노드를 특정하는 부분을 주석 처리했다.

로그를 모아두기만 하면 된다.

--all-containers옵션을 통해 한꺼번에 모든 컨테이너의 값을 가져올 수 있다.
nginx와 httpd가 같은 포트를 열어서 httpd가 꺼진 상황인 듯하다.

과연, 하나만 크룹백이 터지는 중이다.

한 쪽은 주석처리해버렸다.
edit으로 수정해버렸다.

문제 잘못 읽고 계속 실수로 cm을 만들면서 이걸 cm.yaml에 덮어쓰는데 그러지 말자..

help를 통해 만드는 방식을 파악하고 쳐주었다.
제대로 만들어지는 듯하니 이대로 진행

cm.yaml 파일은 이렇게 생겼다.

공식 문서를 참고할 것도 없이 그냥 create -h 쳐서 찾아본다.

트리는 잘 들어갔다.

파일로도 원하는대로 들어간 것 같다.

각각의 서비스를 만들어줘야 한다.

이런 식으로 만들어봤으나, 엔드포인트가 잡히지 않는다.

expose를 통해 뭐가 다른지 살펴본다.

이제 보니까 네임스페이스를 잘못 두고 있었다.

정상적이라면, 이렇게 curl 요청이 잘 먹힌다.

이미 인그레스 컨트롤러는 nginx라는 이름으로 있다.

문제 이해를 잘 못해서 이렇게만 만들었다.
그런데 그냥 성공이 떠서, 풀이 내용을 정리해보려고 한다.

인그레스 클래스 이름을 확인한다.

hosts 들먹이는 건, 그냥 도메인 이름이 어차피 로컬에 지정돼있어서 편하게 도메인 이름 작성하라는 거네..

인그레스는 80,443 포트밖에 지원되지 않는다고 하는데, 노드 번호 30080은 무슨 말인가가 궁금했다.
이건 인그레스를 더 자세히 공부해야 이해할 수 있을 듯.
컨트롤러가 정확하게 동작하는 방식은 무엇인가?
는 조금 공부해보니 알겠다.
기본적으로 노드포트 종류로 서비스가 열리고, 이게 external ip가 부여된다.
이 친구는 내부에 nginx 파드랑 연결된다.
이게 인그레스 컨트롤러가 하는 일.
여기에 관리자가 인그레스를 만들면 nginx 설정 파일에 설정을 가하는 것이다.
그리고 그 방식은,, 내가 여태 많이 해봤던 그냥 서버 블록 넣어주는 작업일 것으로 생각된다.

그러니 30080은 그냥 노드 포트가 무엇인지를 나타낸다.
여기로 들어오는 트래픽이 80으로 연결된다.

각 네임스페이스에 적절한 라벨이랄 게 없으므로, 이름을 라벨로 걸어야겠다.

space2에는 StatefulSet으로 만들어진 파드와 이를 연결하는 Service가 존재한다.

space1에도 마찬가지이다.

네폴의 기준을 네임스페이스로 걸기 위해 각 네스의 라벨을 알아야 한다.

들어오는 트래픽에서는 굳이 포트를 지정하지는 않는다.
이때 주의할 것은, to와 ports는 리스트로 되어 있어야 한다는 것이다.
ports 앞에 -가 없으면, 스페이스2로 나가는 dns 트래픽만 허용된다는 뜻이 된다.

확인

k -n space1 exec app1-0 -- curl -m 1 microservice1.space2.svc.cluster.local
k -n space1 exec app1-0 -- curl -m 1 microservice2.space2.svc.cluster.local
k -n space1 exec app1-0 -- nslookup tester.default.svc.cluster.local
k -n kube-system exec -it validate-checker-pod -- curl -m 1 app1.space1.svc.cluster.local

이것들은 작동해야 한다.
space1에서 2로 가는 요청과, space1에서는 dns가 성공해야 한다.
대신 들어오는 건 자유롭게 받아칠 수 있게 validate으로 실험해본다.

# these should not work
k -n space1 exec app1-0 -- curl -m 1 tester.default.svc.cluster.local
k -n kube-system exec -it validate-checker-pod -- curl -m 1 microservice1.space2.svc.cluster.local
k -n kube-system exec -it validate-checker-pod -- curl -m 1 microservice2.space2.svc.cluster.local
k -n default run nginx --image=nginx:1.21.5-alpine --restart=Never -i --rm  -- curl -m 1 microservice1.space2.svc.cluster.local

이것들은 작동해서는 안 된다.
space1에서는 space2가 아닌 다른 곳으로의 요청은 dns 제외하고는 실패여야 한다.
space2는 space1 말고는 요청을 받으면 안 된다.

문제점은 그냥 단순히 1001 노드에 대해서 허용하는 egress 부분이 오타가 있는 것이었다.
포트를 명시하지 않으니 오히려 문제가 생겼다.

53 dns 요청을 명시한다는 것은 예외 처리를 의미하기라도 하나?
왜 명시하지 않으면 리졸빙이 안 되지?
명확하게 물어보자면, 80번 포트를 명시하지 않았음에도 curl 요청이 가능한 이유가 무엇인가 하는 말이다.

describe를 하고 나서 명확하게 고민이 풀렸다.
문서에서는 port와 to의 조건을 다 만족해야만 한다고 나오는데, 막상 보니까 그렇지 않다.
그냥 각각이 하나의 조건일 뿐이다.
그래서 - 를 어떻게 넣느냐가 중요한 것이다.

대시만 잘 바꾸면 이렇게 특정 네임스페이스로 가는 쪽은 53 포트만 허용하게 할 수도 있다.

그러면 이렇게 level-1000으로는 80 요청이 불가능해진다.
참고로 이건 내가 해당 노드로 53포트를 열었기 때문이 아니라, 그냥 포트 조건이 풀려있어서 그런 것이다.

네폴은 결국 크게 4가지로 접근을 허용할 수 있는 것이다.
포트, 네임스페이스, 파드, ip
거기에 and 조건을 걸어서 조금 더 세밀하게 조건을 걸 수 있다.

이들은 클러스터의 모든 것을 볼 수 있어야 한다.
클러스터롤을 만들고, 바인딩한다.

기본적으로 서아를 만든다.

클러스터 전체에 view를 할 수 있도록, 클러스터롤바인딩을 만든다.

이렇게 하면 view의 권한이 각 서아에 클러스터 전체에 대해서 먹히게 된다.

이후에는 deployment에 create, delete를 할 수 있도록 먼저 롤을 만든다.
매번 느끼지만, 정확하게 리소스 이름을 찾는 게 생각보다 어렵다.
각 네임스페이스에 롤을 만들어도 되는데, 일을 줄이고 싶다면 클러스터롤로 만드는 게 편하다.
클러스터롤을 롤바인딩하면 해당 롤을 받은 개체는 자신의 네임스페이스 안에서만 능력을 발휘할 수 있다는 것을 명심하자.

클롤 하나 만들고 각각을 롤바시키면 된다.
만약 그냥 롤이었어도 작업 방식은 같다.

# namespace ns1 deployment manager
k auth can-i delete deployments --as system:serviceaccount:ns1:pipeline -n ns1 # YES
k auth can-i create deployments --as system:serviceaccount:ns1:pipeline -n ns1 # YES
k auth can-i update deployments --as system:serviceaccount:ns1:pipeline -n ns1 # NO
k auth can-i update deployments --as system:serviceaccount:ns1:pipeline -n default # NO

# namespace ns2 deployment manager
k auth can-i delete deployments --as system:serviceaccount:ns2:pipeline -n ns2 # YES
k auth can-i create deployments --as system:serviceaccount:ns2:pipeline -n ns2 # YES
k auth can-i update deployments --as system:serviceaccount:ns2:pipeline -n ns2 # NO
k auth can-i update deployments --as system:serviceaccount:ns2:pipeline -n default # NO

# cluster wide view role
k auth can-i list deployments --as system:serviceaccount:ns1:pipeline -n ns1 # YES
k auth can-i list deployments --as system:serviceaccount:ns1:pipeline -A # YES
k auth can-i list pods --as system:serviceaccount:ns1:pipeline -A # YES
k auth can-i list pods --as system:serviceaccount:ns2:pipeline -A # YES
k auth can-i list secrets --as system:serviceaccount:ns2:pipeline -A # NO (default view-role doesn't allow)

위 케이스를 전부 통과하면 된다.
쿠버 RBAC의 방식을 잘 보여주는 테스트 방식인 것 같다.
무엇이 무엇에서 무슨 짓을 할 수 있는가?
어떤 역할을 어떤 것에 부여하여 어떤 것을 허용해준다.

이런 식으로 일단 create를 해서 양식을 만드는 게 낫다.
특히 role의 경우에는 apigroups 찾는 것도 일이라..
참고로 찾을 때는 k explain을 해서 해당 리소스의 정보를 찾아보면 조금 도움이 된다.

이런 식으로 api-resources로 찾는 것도 방법이다!
이건 축약어도 알 수 있어서 좋은 듯?

먼저 롤을 만들고, 바인딩한다.

하면서 느끼는 건데 문서가 잘 안 돼 있어서 그냥 create로 어떻게든 만들어내는 게 훨씬 나은 것 같다.
apiGroup 신경 쓰지 않아도 되기도 하고.

kube-system 빼고 모든 네임스페이스에 view 권한을 얻게 하고 싶다면, 그냥 정직하게 그것만 빼고 전부 롤바인딩을 걸어주면 된다.
귀찮지만.. 해주자..
롤 바인딩은 실제로 없는 롤이라도 만들어진다.
그래서 auth로 꼭 확인해주어야 한다.

두 개의 파드가 있고, 우선순위가 많이 높다..
점수가 높은 sprinter 파드를 지우면 끝

현재 존재하는 우선순위들.

기존 파드는 레벨2이다.
그렇다면 레벨3짜리 파드를 만들면 될 것 같다.

만드는 건 간단하다.
네임스페이스를 깜빡했는데, 잘 해주자.

실습 환경의 노드가 하나뿐이라, 내가 실수를 했을 때 기존 파드는 날아가버렸다.
아무튼 그러한 사실, preempted됐다는 사실은 event를 통해 확인할 수 있다.
조금 의아했던 것은 내가 만든 파드를 없앤다고 해서 이미 제거된 파드가 다시 돌아오진 않는다는 것이다.

일단 요구사항을 보자.
내가 설정할 파드는 어떤 노드에 있는 파드를 따라가길 희망해야 한다.
그러니 파드 어피니티에 prefered가 필요하다는 말이다.

노드들의 호스트네임이 각각 다르다.
이 중에서 우리는 호스트네임을 키로 잡고 진행한다.
만약 호스트네임이 같았다면, 스케줄러는 두 노드를 같은 놈이라 간주하고 스케줄링했을 것이다.

라벨 붙은 파드가 존재하며, 이 놈은 node01에 위치한다.
'파드'가 있는 곳을 '선호'하고, level이 restricted여야 한다.
topologyKey, 즉 설정이 걸리게 될 노드의 기준은 호스트네임.

단서를 토대로 Affinity를 구성한다.

파드를 따라가서 노드1에 스케줄링됐다.

문제는 아니고 실습.
정말로 어피니티에 의해 파드가 따라가는 건지 테스트해본다.

이번에는 컨트롤 플레인에 restricted를 넣어본다.

정확하게 스케줄링되고 있다.

위의 문제와 조금만 다르다.
이번에는 선호가 아니라 요구, 라벨이 없어야 한다.

Affinity를 만들었다.
topology 부분을 들여쓰기를 한 칸 지우고, 앞에 topology를 지운다.

성공적으로 다른 노드에 할당이 됐다.

그냥 말 그대로 따라해봤다.

뭔가 실수한 듯한데, 확인해보니 그냥 /bin/bash가 없는 것이었다.

그냥 kubeadm 명령어 help를 쳐보니 각 옵션들이 있어서 선실행을 해봤다.
문제가 있을 수도 있으니 웬만하면 dry run을 먼저 하자.

간단하게 완료.
kubectl을 쓸 수 있게 설정 파일을 가져오는 명령어도 보인다.
그대로 따라해주면 된다.

사실 이건 별로 할 게 없다.
그냥 ssh로 해당 노드에 접근한 뒤에 처음 init할 때 나온 명령어를 다시 쓰는 것 밖에..
kubeadm token create --print-join-command를 해서 토큰을 받아 사용하는 방법도 있다.

현재 버전은 1.31.0이다.
그냥 공식 문서에 있는 코드 그대로 친다.

먼저 가능한 버전을 확인해보니, 다음의 버전들이 있다.
참고로 문서에 있는 코드를 한줄 한줄 치는 게 좋다.
중간 에러가 발생하는 경우 때문에 이후 명령어가 적용 안 되는 경우가 있다.

먼저 kubeadm의 버전을 올려주었다.

업그레이드 플랜을 통해 어떤 것을 사용할 수 있나 나온다.
3버전으로 올릴 수 있을 것처럼 써있지만.. kubeadm이 1버전이라 그렇게는 안 된다고 에러가 뜬다.
apply를 걸어서 실제로 업그레이드하는데는 대략 5분의 시간이 걸린다.

업그레이드가 완료되었으면 아직 동작하고 있는 kubelet을 재시작해줘야 한다.
이때 만약 배포된 리소스가 있다면 드레인 후 작업을 해야 한다.
그리고 kubectl도 업그레이드해줘야 한다!

정리하자면.. 필요한 버전의 kubeadm을 가져와서 온다.
그 놈으로 업그레이드를 진행한다.
그것에 맞게 kubectl, kubelet을 업그레이드한다.
kubelet은 재시작까지 해줘야 한다.

풀이랄 것도 없다..
kubeadm upgrade할 때 아까는 apply 였지만 이번에는 node라는 것 정도.

만약 드레인을 하고 싶다면 kubectl이 먹히는 마스터 노드에서 미리 진행하도록 한다.

조인 커맨드를 어디에서 꺼내나 헷갈렸는데, kubeadm token에서 꺼낼 수 있다.
그냥 컨트롤플레인에서 join 커맨드를 가져오고, 이를 워커 노드에 복붙한다.

그냥 kubeadm 뒤적거리다 보면 나온다.
expires에 해당하는 내용만 파일로 저장해준다.

간단하다.

항상 이런 설정 이슈는 이렇게 하는 방법이 있다는 것을 아는 게 중요하다.
설정법은 결국 간단하기 때문이다.

node01에 위치하고 있다.
정적 파드는 해당 노드에서 자체적으로 양식을 관리하기에 이걸 통째로 옮겨야 한다.

node01에 파드가 위치한다.

그냥 바로 가져와서 이름을 바꿔주면 끝.
노드에 있는 녀석은 지워주도록 한다.